{“error_code”:50001,”message”:”Register schema operation failed while writing to the Kafka store”}
今天被这个异常搞得很头大，创建/更新/删除schema的时候都报50001错误，官方文档上是这么写的Error code 50001 – Error in the backend datastore，应该是访问后端存储，也就是kafka的_schema这个topic失败，具体失败的原因不清楚，所以看看schema registry的日志，然后。。日志里没有错误。。。再看下kafka日志。。也没有错误。。。
搜了一下，github有人提了个issue说是message size过大，调整producer的max.request.size和topic level的message.max.bytes和replica.fetch.max.bytes就好了，但理论上我们应该没有哪个schema会超过1M，一般都不会超过100个字段，但还是调整参数试了一下，没用。。。
没办法只能看源码了，然后发现源码里不！打！印！错！误！日！志！只是封装了Exception的基本信息（Error in the backend datastore。。。）和Error Code返回给客户端，然后详细错误信息。。吞了。。。牛X。。
给exception加上log，重新编译打包重启，问题其实很简单，producer超时了。schema registry默认producer timeout是500ms，可以通过kafkastore.timeout.ms参数修改，调成2000ms问题就解决了。之所以今天会超时，是有一台broker今天下掉做磁盘raid，重新上线之后数据都清空了，需要从别的broker恢复replica，说来惭愧，这台机器还没来得及升万兆网卡，所以流量几乎打满带宽，而_schema这个topic的其中一个备份刚好在这台机器上，并且schema registry producer的acks默认是-1，即要求所有备份完成之后才会返回response，在流量紧张的情况下500ms之内没有完成写入和备份操作，造成超时。这里顺带提一下，带宽不足的情况下，一定注意server properties的num.recovery.threads.per.data.dir的设置，一般千兆带宽的话默认值1已经就是极限了，经过测试设置为2就会压满带宽，数据正常写入和正常备份都会受影响
就这么个小事情浪费了一下午的时间，如果有日志的话应该几分钟就能解决，所以打算把schema registry的日志完善一下，顺便接入日志告警平台，一劳永逸
